home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / winsock / hacker / 93-12 / 000001_ICH211@ZAM001.Z…KFA-JUELICH.DE_Thu Dec 9 13:01:45 1993.msg < prev    next >
Internet Message Format  |  1993-12-30  |  6KB

  1. Received: from zam001.zam.kfa-juelich.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
  2.           id AA11249; Thu, 9 Dec 1993 06:06:01 -0500
  3. Message-Id: <199312091106.AA11249@SunSITE.Unc.EDU>
  4. Received: from DJUKFA11 by ZAM001.ZAM.KFA-JUELICH.DE (IBM VM SMTP V2R2)
  5.    with BSMTP id 2720; Thu, 09 Dec 93 12:04:37 +0100
  6. Date:         Thu, 09 Dec 93 12:01:45 +0100
  7. From: Thomas Heil <ICH211@ZAM001.ZAM.KFA-JUELICH.DE>
  8. Organization: Forschungszentrum Juelich GmbH - Institut fuer Chemie 2
  9. Subject:      How to reset conn. with LWP winsock (SO_LINGER unchangeable)
  10. To: winsock-hackers@sunsite.unc.edu
  11.  
  12. Hello!
  13.  
  14. Perhaps someone can enlighten me:
  15. Novell's LanWorkPlace WINSOCK.DLL does not allow the changing of the
  16. SO_LINGER socket option (it's defaulted to SO_DONTLINGER, and that's the
  17. way it stays). So ... how can I reset a connection when using this
  18. implementation (which is normally done by setting SO_LINGER with a
  19. zero timeout)?
  20.  
  21. /Thomas
  22.  
  23. ---------------------------------------+--------------------------------------
  24. Mail: Thomas Heil                      | EMail: BITNET: ICH211@DJUKFA11.BITNET
  25.       Forschungszentrum Juelich - ICG2 |      Internet: th.heil@kfa-juelich.de
  26.       52425 Juelich                    | Phone: +49 2461 61-6915
  27.       Germany                          | Fax:   +49 2461 61-5346
  28. From paul@atlas.dev.abccomp.oz.au Mon Dec 13 04:21:10 1993
  29. Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
  30.           id AA08119; Sun, 12 Dec 1993 17:10:47 -0500
  31. Received: by usage.csd.unsw.OZ.AU id AA04744
  32.   (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 13 Dec 1993 09:10:45 +1100
  33. Received: by atlas (4.1/1.35)
  34.     id AA18486; Mon, 13 Dec 93 09:21:10 EST
  35. Date: Mon, 13 Dec 93 09:21:10 EST
  36. From: paul@atlas.abccomp.oz.au (Paul Brooks)
  37. Message-Id: <9312122221.AA18486@atlas>
  38. To: phe@farallon.com
  39. Subject: Re: Valid socket
  40. Newsgroups: alt.winsock
  41. In-Reply-To: <phe-081293160217@pingaux.farallon.com>
  42. Organization: TurboSoft Pty Ltd, Sydney, Australia
  43. Cc: winsock-hackers@sunsite.unc.edu
  44.  
  45. In article <phe-081293160217@pingaux.farallon.com> you write:
  46. |Hi:
  47. |
  48. |INVALID_SOCKET is defined as (SOCKET)(~0). Is the value 0 a valid socket? I
  49. |have checked some winsock implementions. They all seemed to start from 1 to
  50. |whatever.
  51.  
  52. >From my reading of the spec, yes, 0 is a valid number for a socket. The ONLY
  53. value not allowed for a socket is ~0, which is defined that way because
  54. a SOCKET is unsigned, so '-1' is not a valid value. In binary, -1 and ~0
  55. both contain all '1' bits.
  56.  
  57.     Note that the value of sockets need not be integers starting from '1'.
  58. It is perfectly possible that some implementations will use other types of
  59. identifiers for sockets, such as near pointers to a descripter block, or
  60. even far pointers in 32-bit versions. You cannot rely on
  61. SOCKET values being simple positive integers, and testing the return result
  62. for being ' <0 ' like much ported Unix code does will bite you badly.
  63.  
  64. -- 
  65. Paul Brooks              |paul@abccomp.oz.au       |Emerging Standard:
  66. TurboSoft Pty Ltd        |pwb@newt.phys.unsw.edu.au|  one that has not yet
  67. 579 Harris St., Ultimo   |                         |  been superseded.
  68. Sydney Australia 2007    |ph: +61 2 281 3155       |  
  69. From phe@farallon.com Fri Dec 13 00:55:46 1993
  70. Received: from farallon.com (farallon.farallon.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
  71.           id AA17677; Mon, 13 Dec 1993 09:53:28 -0500
  72. Received: from waygate.farallon.com ([163.176.8.12]) by farallon.com (4.1/SMI-4.1)
  73.     id AA11379; Mon, 13 Dec 93 06:53:06 PST
  74. Message-Id: <9312131453.AA11379@farallon.com>
  75. Date: 13 Dec 1993 08:55:46 -0800
  76. From: "Ping He" <phe@farallon.com>
  77. Subject: RE: Valid socket
  78. Return-Receipt-To: "Ping He" <phe@farallon.com>
  79. To: "Paul Brooks" <paul@atlas.abccomp.oz.au>
  80. Cc: winsock-hackers@sunsite.unc.edu
  81.  
  82. Thank you for your info.
  83.  
  84. Ping
  85. _______________________________________________________________________________
  86. To: Ping He
  87. Cc: winsock-hackers@sunsite.unc.edu
  88. From: Paul Brooks on Sun, Dec 12, 1993 2:10 PM
  89. Subject: Re: Valid socket
  90. RFC Header:Received: by waygate.farallon.com with SMTP;12 Dec 1993 14:10:29
  91. -0800
  92. Received: from usage.csd.unsw.OZ.AU by farallon.com (4.1/SMI-4.1)
  93.     id AA08359; Sun, 12 Dec 93 14:10:41 PST
  94. Received: by usage.csd.unsw.OZ.AU id AA04744
  95.   (5.65c/IDA-1.4.4 for phe%farallon.com); Mon, 13 Dec 1993 09:10:45 +1100
  96. Received: by atlas (4.1/1.35)
  97.     id AA18486; Mon, 13 Dec 93 09:21:10 EST
  98. Date: Mon, 13 Dec 93 09:21:10 EST
  99. From: paul@atlas.abccomp.oz.au (Paul Brooks)
  100. Message-Id: <9312122221.AA18486@atlas>
  101. To: ping_he.kansas_mail@waygate
  102. Subject: Re: Valid socket
  103. Newsgroups: alt.winsock
  104. In-Reply-To: <phe-081293160217@pingaux.farallon.com>
  105. Organization: TurboSoft Pty Ltd, Sydney, Australia
  106. Cc: winsock-hackers@sunsite.unc.edu
  107.  
  108. In article <phe-081293160217@pingaux.farallon.com> you write:
  109. |Hi:
  110. |
  111. |INVALID_SOCKET is defined as (SOCKET)(~0). Is the value 0 a valid socket? I
  112. |have checked some winsock implementions. They all seemed to start from 1 to
  113. |whatever.
  114.  
  115. >From my reading of the spec, yes, 0 is a valid number for a socket. The ONLY
  116. value not allowed for a socket is ~0, which is defined that way because
  117. a SOCKET is unsigned, so '-1' is not a valid value. In binary, -1 and ~0
  118. both contain all '1' bits.
  119.  
  120.     Note that the value of sockets need not be integers starting from '1'.
  121. It is perfectly possible that some implementations will use other types of
  122. identifiers for sockets, such as near pointers to a descripter block, or
  123. even far pointers in 32-bit versions. You cannot rely on
  124. SOCKET values being simple positive integers, and testing the return result
  125. for being ' <0 ' like much ported Unix code does will bite you badly.
  126.  
  127. -- 
  128. Paul Brooks              |paul@abccomp.oz.au       |Emerging Standard:
  129. TurboSoft Pty Ltd        |pwb@newt.phys.unsw.edu.au|  one that has not yet
  130. 579 Harris St., Ultimo   |                         |  been superseded.
  131. Sydney Australia 2007    |ph: +61 2 281 3155       |